Controllers play a vital role in allocating computer resources. Thus, controllers often are in a central location, and affect the operation of many program strands. Particularly in larger storage controllers, a failure by the controller can lead to large problems in debugging to prevent further problems.
In a CPU-centric world, applications run in LPARs (z/OS) or hosts (Open). These applications can create either single or multiple jobs which are then used to process I/O to and from storage controllers. There are instances where a job can create an error condition on the storage controller which can then affect all jobs and CPUs accessing that controller. In these cases, it would be advantageous if the particular job could be analyzed to see how it contributed to the creation of the error condition on the storage controller (e.g. malformed command syntax, out of sequence commands, etc). However, in the case where a host or LPAR is running multiple jobs simultaneously, it is not always possible for the “offending” job to be identified from data either on the CPU or the storage controller. While current art allows for the creation and logging of job logs on the CPU, unless the error on the storage controller causes a specific job to fail, it is not possible to identify, from the complete list of jobs, which one created the error condition on the storage controller. It is quite common that even when the storage controller data can point to a particular CPU channel path, IT personnel can not say what jobs are running on that path. Without such ability, debugging and determining the source of the problem can be quite time consuming and expensive, as well as frustrating.
It is therefore a challenge to develop strategies for advancing the art to overcome these, and other, disadvantages.